AI and Software Engineering: Will the Twain Ever Meet?

This session will explore the reasons for the lack of impact in four important areas in which AI has been expected to significantly affect real world Software Engineering. The panelists, each representing one of these areas, will respond to the conjecture that these failures rest upon a common cause reliance on isolationist technology and approaches, rather than upon creating additive technology and a.pproaches that can be integrated with other existing capabilities. l?or the purposes of this debate, we’ve divided up the ways that AI could impact Software Engineering into four broad areas, each of which will be represented by one of the panelists: o Development of smart a.pplications (e.g. Expert Systems) e Development of sma.rt application components e Providing intelligence within the system architecture (e.g. in expert databases or intelligent user interfaces) o Using AI to develop software The first three are product related and are concerned with including AI capabilities within delivered applications. The first two address embedding the AI capabilities within the application itself, while the third addresses embedding them within the run-time facilities used by the application. The fourth area concerns the use of AI in the process of generating software. This generated software may be conventional or it may include AI capabilities in one or more of the first three areas. Our expectakions for major impact upon the field of Software Engineering in these four areas, or on the ‘The author’s work is supported by Bhe Defense Advanced Research Projects Agency under NASA-Ames Cooperative Agreement No. NCC Z-520 and contract MDA903-87-C-0641. The views and conclusions are the author’s and should not be interpreted as representing the olficial opinion or policy of DARPA or the U.S. Government. field in genera.1, have been largely unrealized. h/lost obviously, there has been no shift yet in the basic Software Lifecycle that I, among others, predicted would occur. The old Waterfall Lifecycle is still universally employed. In many ways, software is still being managed and produced as it wa.s twenty years ago. Nevertheless, many significant changes have occurred within the Software Engineering community, such as: structured programnling; abstraction and encapsulation; distributed processing; object oriented approaches; the adoption of Unix and C; and most recently, formal methods and specifications. It’s just that these changes have been been initiated and driven by others, not AI. Our major effect on software engineering to date has been in defining, supporting, and getting accepted the iterative development style, especially within the context of prototyping. We a.re thereby also partly responsible for the increased role of prototyping in software development. The argument is not that we’ve had no influence, but that the impact we’ve had has been much, much smaller than expected. Some of the blame for this lack of impact from our field undoubtedly lies within the Softwa.re Engineering Communit~y, but we’ve chosen to focus this debate on our own actions, or the lack thereof, that have crippled this coupling between the two communities. Conjecture: Common Cause Isolationist Technology & Approaches The central conjecture that this panel will debate is that the primary impediment to the impact of AI on Software Engineering is the adoption by the AI field of technologies a.ncl approaches which isolated us from, rather than coupled us to, the Software Engineering community. This isolationism has been manifested in several areas: Idiosyncratic Language Like ot,ller communities, we invented idiosyncratic languages for our own use. \Vha.t differentiated us, was not the existence of such languages, but rather the nature of the differences between them and the BALZER 1123 From: AAAI-90 Proceedings. Copyright ©1990, AAAI (www.aaai.org). All rights reserved.